4장. AI 시스템 평가하기

출처 — Chip Huyen, 『AI 엔지니어링』(한국어판), 4장 (pp. 200~257). 원문 PDF ai_engineering_final_v11_260909.pdf (2026-09-09 판)

모델이 "얼마나 좋은가"가 아니라 "이 애플리케이션에 맞는가"를 재는 법 — 평가 기준을 먼저 정의하고, 그 기준으로 모델을 고르고, 반복 가능한 평가 파이프라인으로 굳히는 순서를 다룬다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 애플리케이션 평가 기준을 도메인 특화 능력·생성 능력·지시 수행 능력·비용과 지연 시간 네 갈래로 구분하여 설명한다
• 사실 일관성을 국소적/전역적으로 나누고, AI 평가자·자체 검증·지식 강화 검증 세 접근을 비교한다
• 모델을 자체 호스팅할지 API로 쓸지 일곱 가지 기준(데이터 프라이버시·데이터 계보·성능·기능·비용·제어·온디바이스 배포)으로 판단한다
• 공개 벤치마크·리더보드의 한계(벤치마크 상관관계·데이터 오염)를 설명하고 자체 평가에 반영한다
• 평가 파이프라인을 3단계(구성 요소별 평가·가이드라인 작성·방법과 데이터 정의)로 설계한다

전체 흐름도

4장. AI 시스템 평가하기
   │
   ├─▶ 1부. 평가 기준 정의 (§1~§6) — "무엇을 잴 것인가"
   │      §1 평가 주도 개발 → §2 도메인 특화 능력
   │      → §3·§4 생성 능력(사실 일관성 · 안전성)
   │      → §5 지시 수행 능력 → §6 비용과 지연 시간
   │
   ├─▶ 2부. 모델 선택 (§7~§9) — "어떤 모델을 쓸 것인가"
   │      §7 선택 과정(하드 속성으로 거르기 → 소프트 속성으로 조정)
   │      → §8 자체 개발 대 상용 구매(일곱 가지 기준)
   │      → §9 공개 벤치마크(선정·집계 → 상관관계 → 데이터 오염)
   │
   └─▶ 3부. 평가 파이프라인 설계 (§10) — "어떻게 재현 가능하게 잴 것인가"
          1단계 구성 요소별 + 턴/작업 기반 평가
          → 2단계 평가 가이드라인·기준표 작성
          → 3단계 평가 방법과 데이터 정의(AI 평가자·주석·슬라이스·표본 크기)
             │
             └─▶ 10장에서 운영 모니터링·사용자 피드백으로 이어져 순환한다

0. 용어 사전

참고 — 위쪽 4개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 해당 장을 먼저 보라.

1. 평가 기준 — 평가 주도 개발

배포는 됐지만 제대로 작동하는지 알 수 없는 애플리케이션과, 아예 배포되지 않은 애플리케이션 중 어느 쪽이 더 나쁠까. 저자가 콘퍼런스에서 물었을 때 대부분은 전자를 더 나쁘다고 답했다 — 유지 보수 비용이 들 뿐 아니라, 나중에 중단하고 싶을 때조차 더 많은 비용이 든다는 이유였다. 애플리케이션의 투자 대비 효과를 확신하지 못하는 사례는 드물지 않다. 차량 가치를 예측하는 모델을 배포한 지 1년이 지나도 예측이 정확한지 전혀 알 수 없었다는 ML 엔지니어 사례, 챗GPT 열풍 속에 급하게 배포한 고객 지원 챗봇이 도움이 되는지 해가 되는지조차 확신하지 못하는 기업들의 사례가 그렇다.

그래서 필요한 것이 평가 주도 개발(evaluation-driven development)이다. 소프트웨어 공학의 테스트 주도 개발(코드를 짜기 전에 테스트부터 쓴다)에서 영감을 받은 접근으로, AI 엔지니어링에서는 "개발하기 전에 평가 기준부터 정의한다"는 뜻이다. 추천 시스템은 참여도·구매 전환율로, 사기 탐지는 예방한 손실액으로, 코딩은 기능적 정확성으로 — 널리 쓰이는 엔터프라이즈 애플리케이션은 대부분 명확한 평가 기준을 갖고 있다. 문제는 이런 평가가 쉬운 애플리케이션에만 관심이 쏠린다는 점이다. 이는 가로등 아래에서만 잃어버린 열쇠를 찾는 것과 같다 — 더 쉬운 방법이지만 열쇠가 거기 있다는 뜻은 아니다. 평가하기 쉬운 방법이 없다는 이유로 판도를 바꿀 애플리케이션을 놓치고 있을 수도 있다. 저자는 그래서 평가를 "AI 도입의 가장 큰 걸림돌이자 기회"로 본다.

애플리케이션을 평가할 기준은 보통 도메인 특화 능력·생성 능력·지시 수행 능력·비용과 지연 시간 네 갈래로 나뉜다. 예를 들어 법률 계약서 요약 모델이라면, 도메인 특화 능력은 "법률 계약서를 얼마나 잘 이해하는가", 생성 능력은 "요약이 얼마나 일관되고 충실한가", 지시 수행 능력은 "길이 제한 같은 요청된 형식을 지켰는가", 비용과 지연 시간은 "이 요약에 얼마가 들고 얼마나 기다려야 하는가"를 각각 답한다. 3장이 평가 방식(퍼플렉시티·기능적 정확성·AI 평가자 등)을 다뤘다면, 이 장은 그 방식들로 무엇을 잴지 — 즉 기준을 정의하는 데서 시작한다.

2. 도메인 특화 능력

코딩 에이전트를 만들려면 코드를 작성할 수 있는 모델이, 번역 애플리케이션이라면 두 언어를 모두 이해하는 모델이 필요하다. 이런 능력을 도메인 특화 능력이라 부르며, 모델 구조·크기 같은 설정과 학습 데이터에 좌우된다 — 학습 중 라틴어를 본 적 없는 모델이 라틴어를 못 하는 것과 같은 이치다. 이를 평가하려고 코드 생성·디버깅·초등 수학·법률 지식·도구 사용 등 수천 개의 공개 벤치마크가 나왔고 지금도 계속 늘어난다.

코딩 능력은 보통 기능적 정확성(§0 용어 사전 참고 — 3장에서 다룬 개념)으로 평가하지만 그것만으로는 부족하다. 잘 달리지만 연료를 지나치게 소비하는 자동차를 아무도 원하지 않듯, SQL 쿼리가 정확해도 실행 시간이 너무 길거나 메모리를 과하게 쓰면 실제로 쓰기 어렵다. BIRD-SQL 벤치마크는 정확성과 함께 실제 실행 시간 비교를 통한 효율성까지 평가한다. 코드 가독성도 중요하지만 정확히 잴 방법이 마땅치 않아 AI 평가자 같은 주관적 평가에 의존하게 된다.

코딩이 아닌 도메인 능력은 주로 객관식 문제로 평가한다. 폐쇄형 출력은 검증과 재현이 쉽기 때문이다. 모델의 수학 능력을 재고 싶을 때, 개방형 방식은 해답 생성을 시키는 것이고 폐쇄형 방식은 선택지 중 정답을 고르게 하는 것이다. 2024년 4월 기준 일루더의 lm-evaluation-harness에 있는 작업의 75%가 UC 버클리의 MMLU, 마이크로소프트의 AGIEval, ARC-C처럼 객관식이었다. MMLU 벤치마크의 문제는 다음과 같은 형태다.

문제: 정부가 독점을 막고 규제하는 이유 중 하나는 무엇인가?
(A) 생산자 잉여가 사라지고 소비자 잉여가 생기기 때문이다.
(B) 독점 가격이 생산 효율성을 보장하지만, 사회의 배분 효율성을 희생하기 때문이다.
(C) 독점 기업이 상당한 연구 개발을 하지 않기 때문이다.
(D) 높은 가격과 낮은 생산량으로 소비자 잉여가 사라지기 때문이다.
정답: (D)

일반적인 지표는 정확도(맞힌 문제 수)이며, 여러 정답이 있는 문제는 점수 체계로 평가한다. 분류는 객관식의 특수한 경우로 모든 문제가 같은 선택지(예: 부정/긍정/중립)를 쓰며, 정확도 외에 F1 점수·정밀도·재현율을 쓴다. 객관식은 만들고 검증하기 쉽고 무작위 베이스라인과 비교하기도 쉽다 — 선택지가 4개면 무작위 정확도는 25%이므로 그보다 높으면 대개(항상은 아니지만) 모델이 무작위보다 낫다는 뜻이다.

다만 객관식은 문제 표현을 조금만 바꿔도 성능이 흔들린다는 단점이 있다. Alzahrani 등(2024)의 연구는 문제와 응답 사이에 공백을 넣거나 "선택지:" 같은 지시 구문을 추가하면 모델이 답을 바꾼다는 것을 보였다(이런 프롬프트 민감도는 5장 §4 명확한 지시와 충분한 컨텍스트에서 더 다룬다). 근본적으로 객관식은 좋은 응답과 나쁜 응답을 "구별하는" 능력(분류)을 재는 것이지 좋은 응답을 "생성하는" 능력을 재는 것이 아니다 — 지식("파리가 프랑스 수도인가")과 추론에는 적합하지만 요약·번역·글쓰기 같은 생성 능력에는 적합하지 않다. 다음 절에서 생성 능력을 다룬다.

3. 생성 능력 — 사실 일관성

생성형 AI가 화제가 되기 훨씬 전부터 NLP 연구자들은 개방형 출력의 품질을 연구해 왔다. 2010년대 초반 자연어 생성(NLG) 작업 — 번역·요약·바꿔쓰기 — 은 유창성(문법적으로 자연스러운지)과 일관성(전체가 논리적으로 구조화됐는지)으로 평가받았다. 번역에는 충실성(원문 의미를 얼마나 담았는지), 요약에는 관련성(원문의 핵심을 얼마나 다뤘는지)처럼 작업별 지표도 있었다. 생성 모델의 텍스트가 사람 글과 구분하기 어려워지면서 유창성·일관성의 중요성은 낮아졌지만, 성능이 떨어지는 모델이나 저자원 언어를 다룰 때는 여전히 유용하다. 이 지표들은 AI 평가자로 묻거나 퍼플렉시티로 잴 수 있다(§0 용어 사전 — 둘 다 3장에서 소개된 개념).

생성 모델이 새로 가져온 문제 중 가장 시급한 것은 원치 않는 환각이다. 환각은 창의적 작업에는 바람직할 수 있지만 사실 관계가 중요한 작업에는 그렇지 않다. 애플리케이션 개발자가 가장 많이 재려 하는 지표가 바로 사실 일관성이며, 사실 비일관성이 안전성 문제에 속함에도(사용자에게 해를 끼칠 수 있으므로) 범위가 넓어 이 장에서는 따로 다룬다.

국소적 사실 일관성은 주어진 컨텍스트를 기준으로 판단한다 — 모델이 "하늘은 파랗다"라고 답했는데 컨텍스트가 "하늘은 보라색이다"라면 이 출력은 사실과 다르다. 요약이 원문을 반영해야 하는 요약 작업, 응답이 회사 정책에 부합해야 하는 고객 지원 챗봇에서 중요하다. 전역적 사실 일관성은 공개된 지식을 기준으로 판단한다 — "하늘은 파랗다"가 일반적으로 받아들여지는 사실이면 진술은 사실과 같다고 본다. 일반 챗봇·사실 확인·시장 조사처럼 광범위한 작업에서 중요하다.

명시적 사실("백신과 자폐증 사이에 입증된 연관성은 없다")은 확인이 비교적 쉽지만, 컨텍스트가 없으면 먼저 신뢰할 만한 출처를 찾고 사실을 도출해야 한다. 사실 일관성 검증에서 가장 어려운 부분은 "무엇이 사실인가"를 판단하는 일 자체다 — "메시는 세계 최고의 축구 선수다" 같은 진술이 사실인지는 어떤 출처를 신뢰하는지에 달려 있다. 인터넷은 허위 정보로 넘쳐나고, 증거 부재를 근거로 "연관성이 없다"를 사실로 받아들이는 오류에도 빠지기 쉽다. Wan 등(2024)의 연구는 기존 모델이 과학적 참고 문헌이 있는지 같은 문체적 특징은 거의 고려하지 않고 웹사이트·질의의 관련성에만 과하게 의존한다고 지적했다.

환각을 잘 일으키는 질의 유형은 두 가지다. 첫째, 최소한의 지식을 요구하는 질의 — 국제수학올림피아드(IMO)보다 덜 알려진 베트남수학올림피아드(VMO)에 대한 질의에서 환각이 더 자주 일어난다. 둘째, 존재하지 않는 정보를 묻는 질의 — "X가 Y에 대해 뭐라고 말했나"를 물었을 때 X가 실제로 언급한 적이 없다면, 언급한 적이 있는 경우보다 환각 가능성이 높다.

컨텍스트가 이미 있다고 가정하면(컨텍스트 검색은 6장 §1·§2에서 다룬다), 가장 직관적인 방법은 AI 평가자를 쓰는 것이다. Liu 등(2023)과 Luo 등(2023)은 GPT-3.5·GPT-4가 사실 일관성 측정에서 기존 방법보다 뛰어나다는 것을 보였고, TruthfulQA 논문(Lin et al., 2021)은 파인튜닝된 GPT 평가자가 사람이 진실이라 판단하는 진술을 90~96% 정확도로 예측한다고 보고했다. 더 정교한 기법으로는 두 가지가 있다.

자체 검증(self-verification) — SelfCheckGPT(Manakul et al., 2023)는 모델이 서로 일치하지 않는 여러 출력을 낼 때 원래 출력이 환각일 가능성이 높다는 가정을 쓴다. 응답 R이 주어지면 N개의 새 응답을 생성해 R이 그 N개와 얼마나 일치하는지 측정한다. 효과는 있지만 AI 질의를 많이 써야 해서 비용이 크다.

지식 강화 검증(knowledge-augmented verification) — 구글 딥마인드의 검색 증강 사실성 평가기 SAFE는 검색 엔진 결과로 응답을 검증한다. ① AI로 응답을 문장 단위로 분리 → ② 각 문장이 독립적으로 이해되도록 수정("20세기에 개장했다"의 주어를 원래 주어로 복원) → ③ 각 문장에 대해 검색 질의를 제안 → ④ AI로 문장이 검색 결과와 일치하는지 판단하는 4단계를 거친다.

이 과정은 오래된 NLP 과제인 텍스트 함의(자연어 추론, NLI)로 표현할 수 있다. 전제(컨텍스트)가 주어지면 가설(출력)이 함의(전제로부터 추론 가능)·모순·중립 중 어디에 속하는지 판단한다. "메리는 모든 과일을 좋아한다"가 전제라면 "메리는 사과를 좋아한다"는 함의, "메리는 오렌지를 싫어한다"는 모순, "메리는 닭고기를 좋아한다"는 중립이다. 함의는 사실 일관성을, 모순은 비일관성을, 중립은 판단 불가를 뜻한다.

범용 AI 평가자 대신 사실 일관성 예측에 특화된 평가 모델을 학습시킬 수도 있다. (전제, 가설) 쌍을 입력받아 함의·모순·중립을 출력하면 사실 일관성을 분류 문제로 바꿀 수 있다 — 예를 들어 DeBERTa-v3-base-mnli-fever-anli는 76만 4천 개의 주석 쌍으로 학습된 1억 8,400만 파라미터 모델이다.

사실 일관성 벤치마크로는 TruthfulQA가 있다. 사람이 잘못된 믿음으로 부정확하게 답할 수 있는 817개 질의(건강·법률·금융·정치 등 38개 분야)로 구성되며, 참조 응답과 비교해 사실성을 자동 평가하도록 파인튜닝된 GPT-judge와 함께 제공된다. 사람 전문가 베이스라인은 94%로 보고됐다. 사실 일관성은 검색 증강 생성(RAG) 시스템의 핵심 평가 기준이기도 하다 — 생성된 응답은 검색된 컨텍스트와 사실 일관성이 있어야 하며, RAG는 6장의 핵심 주제다.

4. 생성 능력 — 안전성

사실 일관성 외에도 모델 출력이 해로울 수 있는 경우가 많다. 안전성 솔루션마다 위험을 분류하는 방식이 다르지만, 오픈AI의 콘텐츠 중재 엔드포인트나 메타의 Llama Guard 논문(Inan et al., 2023)에 정의된 분류법을 참고할 수 있다(모델이 가진 위험성과 안전 조치는 5장에서 더 다룬다). 위험한 콘텐츠는 보통 다음과 같이 나뉜다.

1. 욕설과 노골적인 내용을 포함한 부적절한 언어
2. "은행 강도 단계별 가이드"처럼 유해한 추천과 지침
3. 인종·성·성적 지향에 대한 차별 발언을 포함한 혐오 발언
4. 위협과 자세한 묘사를 포함한 폭력
5. 특정 직업에 고정된 성별을 부여하는 것 같은 고정관념
6. 정치·종교 이데올로기에 대한 편향성 — Feng 등, Motoki 등, Hartman 등의 여러 연구는 모델이 학습 데이터에 따라 정치적 편향을 갖게 된다는 것을 보였다(2023년 무렵의 한 조사에서는 오픈AI의 GPT-4가 자유주의적 성향이 강했던 반면 메타의 라마는 더 권위주의적 성향을 보였다 — 특정 모델 세대의 스냅샷이며 현재도 같은 성향이라는 뜻은 아니다)

이런 시나리오는 범용 AI 평가자로 감지할 수 있고, 실제로 널리 쓰인다. 다만 유해한 콘텐츠는 AI가 만든 것에만 있지 않다 — 온라인에는 이미 많은 유해 콘텐츠가 있어, 사람이 쓴 텍스트의 유해성을 감지하도록 학습된 모델을 AI 텍스트에도 그대로 쓸 수 있다. 이런 특수 목적 모델은 범용 AI 평가자보다 작고 빠르고 저렴하다(메타의 혐오 발언 감지 모델 등). 유해성 측정 벤치마크로는 RealToxicityPrompts(Gehman et al., 2020)와 BOLD(Dhamala et al., 2021)가 있다. RealToxicityPrompts는 모델이 유해한 결과물을 내도록 유도할 가능성이 높은 10만 개의 자연스러운 프롬프트(예: "그래서, 그녀가 완전히 ~이라고 생각하기 시작했어" 같은 미완성 문장)로 구성된다.

5. 지시 수행 능력

지시 수행 능력은 "이 모델이 주어진 지시를 얼마나 잘 따르는가"를 묻는다. 지시를 못 따르면 지시 자체가 아무리 좋아도 결과물은 좋을 수 없다. 지시를 따르는 능력은 파운데이션 모델의 핵심 요구사항이며 대부분의 모델이 이를 위해 별도로 학습된다 — 챗GPT의 전신 InstructGPT라는 이름 자체가 지시를 따르도록 파인튜닝됐다는 데서 왔다. 트윗 감성을 부정/긍정/중립으로 출력하라고 했는데 행복/분노 같은 예상 밖 답을 낸다면, 모델이 감성 분석이라는 도메인 능력은 있어도 지시 수행 능력이 부족하다는 뜻이다.

지시 수행 능력은 JSON·정규표현식 같은 구조화된 출력(§0 용어 사전 — 2장에서 다룬 개념)이 필요한 애플리케이션에서 필수적이다. 하지만 구조화된 출력을 내는 것 이상을 의미하기도 한다 — "4글자 이하의 단어만 쓰라"는 지시는 출력이 구조화될 필요는 없지만 여전히 따라야 하는 지시다. 지시 수행 능력은 도메인별 능력·생성 능력과 쉽게 혼동될 수 있어 정의·측정이 쉽지 않다. 베트남 운문 형식 'luc bat'을 써 달라고 했을 때 실패한다면, 그 형식을 쓸 줄 몰라서인지 지시 자체를 이해하지 못해서인지 구분하기 어렵다.

주의 — 모델의 성능은 지시의 품질에 좌우되므로 평가가 어렵다. 성능이 나쁠 때 모델이 나쁜 건지 지시가 나쁜 건지 알기 어려울 수 있다.

IFEval(구글)은 모델이 예상된 형식에 맞는 출력을 내는지에 초점을 맞춘다. Zhou 등(2023)은 키워드 포함·길이 제한·JSON 형식 등 자동으로 검증 가능한 25가지 지시 유형을 정의했다 — 예를 들어 특정 단어를 포함해 문장을 쓰라는 지시는 출력에 그 단어가 있는지 프로그램으로 바로 확인할 수 있다. 이런 유형에는 키워드 포함·키워드 빈도·금지 단어·응답 언어·문단 수·단어 수·문장 수·추신 포함·불릿 개수·제목 포함·섹션 수·JSON 형식 등이 있으며, 지표는 "전체 지시 대비 정확히 따른 지시의 비율"이다.

INFOBench(Qin et al., 2024)는 지시 수행의 의미를 훨씬 넓게 본다. IFEval처럼 형식을 볼 뿐 아니라 내용 제약("기후 변화만 논의하라")·언어 지침("빅토리아 시대 영어를 사용하라")·문체 규칙("존중하는 어조를 사용하라")까지 평가한다. 다만 이렇게 확장된 지시는 자동 검증이 쉽지 않다. INFOBench 연구자들은 각 지시를 예/아니오로 답할 수 있는 기준 질의 목록으로 바꿨다 — "호텔 손님이 리뷰를 쓰는 데 도움이 되는 설문지를 만들라"는 지시라면 "① 생성된 텍스트가 설문지인가? ② 호텔 손님을 위해 설계됐는가? ③ 리뷰 작성에 도움이 되는가?" 세 질의로 검증한다. 지시에 세 기준이 있고 둘을 충족하면 점수는 2/3이며, 최종 점수는 맞힌 기준 수를 전체 기준 수로 나눈 값이다. INFOBench 연구자들은 GPT-4가 사람 전문가만큼 정확하진 않아도 아마존 메커니컬 터크 평가자보다는 정확한, 합리적이고 비용 효율적인 평가자라는 것을 발견했다.

IFEval·INFOBench 같은 벤치마크는 감을 잡는 데 도움이 되지만 둘 다 실제 세계의 지시 분포를 완전히 대표하지는 못한다. TIP 원문의 조언대로, 자신만의 기준으로 벤치마크를 만드는 것이 낫다 — 모델이 YAML을 출력해야 한다면 벤치마크에 YAML 지시를 포함시켜야 한다.

현실에서 자주 보는 지시 유형 하나는 역할 연기다 — 모델에게 가상 캐릭터나 페르소나를 맡기는 것으로, 사용자와 상호작용하는 캐릭터를 연기하는 목적(게임·대화형 스토리텔링)과 출력 품질을 높이는 프롬프트 기법으로서의 목적(5장에서 다룬다) 두 가지로 쓰인다. LMSYS의 백만 대화 데이터셋에서 역할 연기는 여덟 번째로 많은 활용 사례였다. 역할 연기 평가는 자동화가 어렵다 — RoleLLM(Wang et al., 2023)과 CharacterEval(Tu et al., 2024)이 대표 벤치마크이며, 말투(역할다움)와 지식(역할이 알 법한 내용) 두 측면을 함께 평가해야 한다. 지식 측면은 까다로운데, 역할 연기 모델이 그 캐릭터가 모를 법한 것을 말하면 안 되기 때문이다 — 게임에서 NPC가 실수로 플레이어에게 스포일러를 하면 안 되는 것과 같은 이치다.

6. 비용과 지연 시간

품질이 아무리 좋아도 너무 느리고 비싸면 쓸모가 없다. 평가할 때는 품질·지연 시간·비용의 균형을 맞춰야 하며, 많은 기업이 비용과 지연 시간이 더 나은 저품질 모델을 택한다(비용·지연 시간 최적화는 9장 §4·§5에서 자세히 다룬다). 여러 목표를 동시에 최적화하는 문제를 파레토 최적화라 부르며, 타협 불가능한 기준부터 명확히 정하는 것이 실무의 출발점이다 — 지연 시간을 타협할 수 없다면 먼저 요구사항을 충족 못 하는 모델을 제외한 뒤 남은 것 중 가장 좋은 것을 고른다.

지연 시간 지표는 첫 토큰까지 걸리는 시간·토큰당 시간·토큰 간 시간·질의당 시간 등 여러 가지이며, 목표에 따라 어떤 지표가 중요한지가 달라진다. 지연 시간은 모델 자체뿐 아니라 프롬프트·샘플링 설정에도 좌우된다 — 생성해야 할 토큰이 많을수록 전체 지연 시간이 길어지므로, 간단히 답하라는 지시나 생성 중단 조건(2장 §4 샘플링에서 다룬 개념) 설정으로 체감 지연 시간을 줄일 수 있다.

TIP — 지연 시간을 평가할 때는 "반드시 필요한 것"과 "있으면 좋은 것"을 구분해야 한다. 낮은 지연 시간을 원하는지 물으면 아니라고 할 사람은 없지만, 대개 긴 지연 시간은 불편할 뿐 사용을 포기할 만큼 치명적이지는 않다.

모델 API는 보통 토큰 단위 과금이라 입출력 토큰이 많을수록 비용이 커지며, 많은 애플리케이션이 토큰 수를 줄여 비용을 관리한다. 자체 호스팅은 엔지니어링 비용을 빼면 주요 비용이 컴퓨팅 자원이며, GPU 메모리 구성(16·24·48·80GB)에 맞춰 모델 크기(70억·650억 파라미터 등)를 고르는 경우가 많다. 모델 API는 규모가 커져도 토큰당 비용이 크게 변하지 않지만, 자체 호스팅은 규모가 커질수록 토큰당 비용을 줄일 수 있다 — 하루 10억 토큰을 처리할 클러스터에 이미 투자했다면 100만 토큰을 쓰든 10억 토큰을 쓰든 컴퓨팅 비용은 같다.

애플리케이션에 쓸 모델을 고를 때는 비용(출력 토큰당 비용)·규모(분당 토큰 수, TPM)·지연 시간(첫 토큰까지 시간·총 쿼리 시간, 보통 P90 기준)·품질(Elo 점수·챗봇 아레나 순위·코드 생성 pass@k·사실 일관성)처럼 여러 기준을 함께 표로 정리해 두는 것이 실무에서 쓰인다. 특히 규모 요구사항은 모델 API가 필요한 트래픽을 감당할 수 있는지 확인하는 데 중요하다.

7. 모델 선택 과정

결국 중요한 것은 "어떤 모델이 가장 좋은가"가 아니라 "우리 애플리케이션에 가장 적합한 모델이 무엇인가"다. 애플리케이션 기준을 정했다면 그 기준으로 모델을 평가해야 한다. 프롬프트 엔지니어링은 전반적으로 가장 성능 좋은 모델로 시작해 더 작은 모델로도 되는지 확인하는 식으로, 파인튜닝은 작은 모델로 코드를 검증한 뒤 하드웨어 제약(GPU 1개 등)에 맞는 가장 큰 모델로 확장하는 식으로 반복적으로 모델을 고르게 된다. 일반적으로 선택 과정은 ① 달성 가능한 최고 성능 파악 ② 비용-성능 축에서 투자 대비 최고 성능 모델 선택, 두 단계로 요약되지만 실제 과정은 더 복잡하다.

모델을 볼 때는 바꾸기 어렵거나 비현실적인 하드 속성(라이선스·학습 데이터·모델 크기 — 모델 제공업체의 결정이나 자체 정책의 결과인 경우가 많다)과, 개선할 수 있는 소프트 속성(정확도·유해성·사실 일관성)을 구별하는 것이 중요하다. 소프트 속성을 얼마나 개선할 수 있는지 추정하는 데는 낙관과 현실 사이 균형이 필요하다 — 저자도 첫 프롬프트에서 정확도 20%에 머물다 작업을 두 단계로 나누자 70%까지 오른 경험이 있었던 반면, 몇 주를 조정해도 못 쓸 수준이라 포기한 모델도 있었다. 지연 시간처럼 최적화로 바꿀 수 있으면 소프트 속성이지만, 다른 사람이 호스팅하는 모델을 쓴다면 하드 속성이 된다 — 하드/소프트의 경계는 모델과 활용 사례에 따라 달라진다.

전반적인 평가 과정은 네 단계로 이뤄진다.

1. 하드 속성이 맞지 않는 모델을 걸러낸다(자체 정책·API 대 자체 호스팅 여부에 따라 목록이 크게 달라진다)
2. 공개된 벤치마크·리더보드 순위로 실험해 볼 유망한 모델을 추린다(품질·지연 시간·비용을 함께 고려)
3. 자체 평가 파이프라인으로 실험해 최적 모델을 찾는다(§10에서 다룰 설계)
4. 운영 환경에서 지속적으로 모니터링해 실패를 감지하고 피드백을 모은다(10장에서 다룬다)

이 네 단계는 순환적이다 — 처음에는 오픈 소스 모델을 호스팅하려 했다가, 평가 후 원하는 성능을 못 낸다는 것을 깨닫고 상업용 API로 바꾸는 식으로 이전 결정을 뒤집을 수 있다. 다음 §8에서는 첫 갈림길인 "자체 개발 대 구매"를, §9에서는 공개 벤치마크를 살펴본다.

8. 모델 자체 개발 대 상용 모델 구매

대부분의 기업은 파운데이션 모델을 처음부터 개발하지 않으므로, 이 고민은 "상용 모델 API를 쓸지 오픈 소스 모델을 직접 호스팅할지"로 좁혀진다.

오픈 소스, 오픈 가중치, 라이선스 — "오픈 소스 모델"이라는 말은 이제 논쟁적이다. 원래는 다운로드해 쓸 수 있는 모든 모델을 가리켰지만, 일부는 학습 데이터까지 공개돼야 진짜 오픈이라 주장한다. 이 책은 단순화를 위해 학습 데이터 공개 여부와 무관하게 가중치가 공개된 모델을 오픈 소스로 부른다. 데이터 없이 공개된 모델은 오픈 웨이트, 데이터까지 공개된 모델은 오픈 모델이라 구분한다. 현재 오픈 소스 모델 대다수는 오픈 웨이트에 그친다 — 개발자들이 학습 데이터 정보를 공개하면 비판이나 소송에 노출될 수 있어 의도적으로 숨기기 때문이다. 라이선스도 제각각이다(라마 2·3의 "커뮤니티 라이선스", 빅코드의 "오픈 RAIL-M" 등). 확인해야 할 질문은 ① 상업적 사용을 허용하는가 ② 어떤 제한이 있는가(예: 대규모 사용자 기준 별도 라이선스 요구) ③ 모델 출력을 다른 모델 학습(모델 증류 등, 8장 §5 데이터 수집과 주석에서 이어지는 데이터 합성 논의)에 쓰는 것을 허용하는가다.

사용자가 모델에 접근하는 구조 — 모델을 호스팅하고 질의를 받아 응답을 반환하는 서비스를 추론 서비스라 하고, 사용자가 접하는 인터페이스가 모델 API다. 모델 개발자는 오픈 소스로 공개하거나 API로 제공하거나 둘 다 할 수 있다(코히어·미스트랄처럼). 같은 모델도 제공업체(모델 개발사·클라우드·서드파티)에 따라 기능·제약·가격이 다를 수 있어, API를 전환할 때는 철저한 테스트가 필요하다.

이제 자체 호스팅과 API 사용을 가르는 일곱 가지 기준을 하나씩 본다.

• 데이터 프라이버시 — 데이터를 조직 밖으로 보낼 수 없는 기업은 외부 호스팅 API를 쓸 수 없다. 삼성 직원들이 기밀 정보를 챗GPT에 입력해 유출된 사건(2023년 4월)이 처음 크게 알려졌고, 삼성은 2023년 5월 챗GPT를 금지했다. 또한 API 제공업체가 사용자 데이터로 자사 모델을 학습할 위험도 있다 — 정책은 언제든 바뀔 수 있으며, 줌(Zoom)이 서비스 약관을 조용히 바꿔 반발을 산 사례(2023년 8월)가 있다. 허깅페이스의 StarCoder 모델이 학습 데이터셋의 8%를 기억한다고 밝혀진 사례처럼, 학습 샘플이 그대로 기억돼 유출될 위험도 있다.
• 데이터 계보와 저작권 — 대부분 모델이 어떤 데이터로 학습됐는지는 투명하지 않다. AI 관련 지적재산권법은 계속 진화 중이며(미국 특허청이 "AI 보조 발명도 특허 가능"이라 밝힌 것이 2024년 사례), 저작권 있는 데이터로 학습한 모델로 만든 제품의 지적재산권을 지킬 수 있을지는 불분명하다. 데이터 계보 우려로 일부 기업은 학습 데이터까지 공개하는 완전 개방형 모델로 방향을 틀지만, 실제로는 그 규모의 데이터셋을 철저히 검사하기가 쉽지 않다.
• 성능 — 여러 벤치마크에서 오픈 소스와 독점 모델의 격차가 좁혀지고 있지만, 가장 강력한 모델을 가진 쪽은 그것을 공개하기보다 직접 수익화하려는 유인이 크므로 최고 성능 오픈 소스가 최고 성능 독점 모델을 당분간 따라잡기는 어려워 보인다. 오픈 소스 개발자는 상용 모델만큼 사용자 피드백을 받아 모델을 개선하기도 어렵다.
• 기능 — 확장성·함수 호출(6장의 RAG·에이전트 활용 사례에 필요)·구조화된 출력·출력 가드레일 같은 기능은 직접 구현하기 어렵고 시간이 든다. 특히 로그프롭(logprobs, 분류·평가·해석에 유용)은 모델 복제를 막으려고 상용 API가 공개를 꺼리는 대표적 기능이다. 파인튜닝도 제공업체가 허용하는 범위 안에서만 가능하다(파인튜닝의 종류는 7장 §1·§5에서 자세히 다룬다).
• 비용 — API는 사용량에 따라 과금돼 규모가 커지면 비용이 부담스러워질 수 있는 반면, 자체 호스팅은 최적화·확장·유지에 상당한 엔지니어링 노력이 든다. "API도 비싸지만 엔지니어링은 더 비쌀 수 있다."
• 제어 — 독점 모델은 검열이 과도한 쪽으로 치우치기 쉽다. 3D 환경에서 상호작용하는 AI 캐릭터를 만드는 콘바이(Convai)는 상용 모델이 "저는 물리적 능력이 없습니다" 같은 응답을 반복해 결국 오픈 소스 모델을 파인튜닝하는 쪽으로 결정했다 — 실제 얼굴 생성을 거부하는 안전 가드레일이 뮤직비디오 제작 같은 정당한 용례까지 막았기 때문이다. 상용 모델은 갑자기 접근 권한을 잃거나 예고 없이 변경될 위험도 있다(2023년 이탈리아가 일시적으로 오픈AI를 금지한 사례처럼 국가 단위 금지도 가능하다).
• 온디바이스 배포 — 인터넷이 불안정한 지역이나, 데이터가 기기를 벗어나면 안 되는 프라이버시 요구가 있는 경우 서드파티 API는 쓸 수 없고 로컬 실행이 필요하다.

판단 시나리오 — 콘바이(Convai)의 3D 캐릭터 — 상황: 물건을 집는 등 3D 환경에서 상호작용하는 AI 캐릭터가 필요하다. 잘못된 접근: 상용 모델을 그대로 채택 → 모델이 "저는 물리적 능력이 없는 AI입니다"를 반복해 캐릭터의 몰입감이 깨진다. 올바른 접근: 오픈 소스 모델을 목적에 맞게 파인튜닝한다. 왜: 상용 모델의 안전 가드레일(제어 기준)이 이 활용 사례에는 과도한 제약이었고, 하드 속성(제공업체 정책)을 바꿀 수 없었으므로 소프트 속성(모델 자체를 조정할 수 있는 오픈 소스 여부)으로 문제를 옮긴 것이다.

9. 공개 벤치마크 탐색하기

모델의 다양한 능력을 재려고 수천 개의 벤치마크가 나와 있다 — 구글의 BIG-bench(2022)만 해도 214개를 담고 있다. 여러 벤치마크를 한 번에 돌려 주는 도구를 평가 하네스라 하며, 일루더의 lm-evaluation-harness는 400개 이상, 오픈AI의 evals는 약 500개의 벤치마크를 지원한다.

벤치마크 선택과 집계, 리더보드 — 벤치마크 결과를 집계해 모델 순위를 매긴 것이 리더보드다. 리더보드를 만들 때는 "어떤 벤치마크를 포함할까"와 "결과를 어떻게 집계할까" 두 질문을 풀어야 한다. 컴퓨팅 자원 제약 때문에 대부분 소수의 벤치마크만 포함하며(HELM Lite가 비용이 큰 정보 검색 벤치마크를 뺀 것, 허깅페이스가 HumanEval을 뺀 것이 예다), 리더보드마다 다른 벤치마크를 쓰다 보니 서로 비교하기도 어렵다. 허깅페이스의 오픈 LLM 리더보드는 2023년 4개 벤치마크로 시작해 그해 말 6개(ARC-C·MMLU·HellaSwag·TruthfulQA·WinoGrande·GSM-8K)로 확장했지만, 스탠퍼드의 HELM 리더보드는 같은 시기 10개 벤치마크(MMLU·GSM-8K만 겹침, 나머지는 MATH·LegalBench·MedQA·WMT 2014 번역·NarrativeQA·OpenBookQA·Natural Questions 등)를 썼다. 벤치마크가 왜 그렇게 골라졌는지 리더보드 개발자 스스로도 명확히 설명하지 못하는 경우가 많다.

벤치마크를 고를 때 놓치기 쉬운 것이 상관관계다. 두 벤치마크가 강하게 상관돼 있다면 둘 다 쓸 필요가 없다. 2024년 1월 계산된 허깅페이스 리더보드 6개 벤치마크의 상관관계를 보면, ARC-C·MMLU·WinoGrande는 모두 추론 능력을 재기 때문에 서로 강하게(대략 0.85 이상) 상관돼 있었던 반면 TruthfulQA는 다른 벤치마크들과 중간 정도의 상관관계만 보였다 — 추론·수학 능력이 좋아진다고 진실성까지 함께 좋아지는 건 아니라는 뜻이다. (원문의 상관계수 표는 추출 과정에서 열·값이 뒤섞여 정확한 수치로는 옮기지 않는다 — 위 서술은 본문이 분명히 밝힌 정성적 관계만 반영한 것이다.) 평균으로 집계하면 모든 벤치마크를 동등하게 취급하는 셈이 된다는 문제도 있다 — TruthfulQA의 80점이 GSM-8K의 80점보다 얻기 어려울 수 있는데도 같은 값으로 계산된다. HELM 연구자들은 평균 대신, 한 모델이 다른 모델보다 나은 점수를 얻는 비율을 시나리오별로 평균 낸 평균 승률을 쓴다.

포화와 재편 — 많은 벤치마크가 빠르게 포화 상태가 된다. 허깅페이스는 2024년 6월 리더보드를 완전히 새 벤치마크 세트로 교체했다 — GSM-8K는 더 어려운 MATH Lvl 5로, MMLU는 MMLU-PRO(Wang et al., 2024)로 바뀌었고, GPQA(대학원 수준 질의응답)·MuSR(다단계 추론)·BBH(추론)·IFEval(지시 수행)이 새로 포함됐다.

오픈AI 모델의 성능이 나빠지고 있을까 — 스탠퍼드·UC 버클리 연구(Chen et al., 2023)는 2023년 3월과 6월 사이 GPT-3.5·GPT-4의 성능이 여러 벤치마크에서 눈에 띄게 달라졌다는 것을 보였다(당시 사례로, 오픈AI가 의도적으로 성능을 낮췄다는 뜻은 아니다). 저자는 평가 자체가 어렵다는 점, 그리고 "전반적으로 가장 좋은 모델이 특정 용도에 가장 적합한 모델은 아닐 수 있다"는 점을 이유로 든다. 실제로 같은 모델 업데이트가 어떤 애플리케이션(Voiceflow의 의도 분류)에서는 성능이 떨어지고 다른 애플리케이션(GoDaddy의 고객 지원 챗봇)에서는 개선된 사례가 있었다.

맞춤형 리더보드 만들기 — 특정 애플리케이션용 모델 평가는 사실상 자신만의 리더보드를 만드는 일이다. 코딩 에이전트라면 코드 벤치마크를, 글쓰기 도우미라면 창의적 글쓰기 벤치마크를 살펴본다. 벤치마크 실행에는 비용이 든다 — 스탠퍼드는 HELM으로 30개 모델을 평가하는 데 약 8만~10만 달러를 썼다(상용 API 3만 8천 달러, 오픈 모델 GPU 시간 1만 9,500시간 기준).

공개 벤치마크의 데이터 오염 — 데이터 오염은 모델이 평가 데이터로 학습돼 실제보다 높은 점수를 받는 현상으로, 데이터 유출·부정행위라고도 부른다. 스탠퍼드 박사과정 학생 Rylan Schaeffer는 풍자 논문 "Pretraining on the Test Set Is All You Need"(2023)에서 벤치마크 데이터로만 학습한 100만 파라미터 모델이 훨씬 큰 모델보다 좋은 점수를 받는 것을 보여줬다. 오염은 대부분 의도치 않게 일어난다 — 인터넷에서 수집한 학습 데이터에 공개 벤치마크가 실수로 섞여 들어가거나, 평가·학습 데이터가 같은 출처(예: 같은 수학 교과서)에서 나오는 간접 오염도 있다. 좋은 의도의 오염도 있다 — 사용자에게 공개하기 전 벤치마크 데이터로 모델을 더 학습시켜 성능을 높이는 경우, 사용자에게는 좋은 모델이지만 그 벤치마크로는 더 이상 평가할 수 없게 된다.

오염 감지에는 두 가지 휴리스틱이 쓰인다. n-gram 중복은 평가 샘플의 토큰 시퀀스가 학습 데이터에도 있는지 보는 방법으로 정확하지만 학습 데이터 전체와 비교해야 해서 비용이 크고, 학습 데이터에 접근할 수 없으면 아예 쓸 수 없다. 퍼플렉시티는 평가 데이터에 대한 퍼플렉시티가 유난히 낮으면(모델이 쉽게 예측하면) 이미 봤을 가능성으로 해석하는 방법으로 정확도는 떨어지지만 자원이 훨씬 적게 든다. 오픈AI는 GPT-3의 오염도를 분석해 학습 데이터에 40% 이상 겹치는 벤치마크가 13개나 된다는 것을 발견했다(Brown et al., 2020). 허깅페이스 같은 리더보드 주최측은 이상치를 감지하려고 벤치마크별 성능 표준편차를 그래프로 살핀다.

공개 벤치마크는 나쁜 모델을 걸러내는 데는 유용하지만 애플리케이션에 가장 맞는 모델을 찾는 데는 도움이 되지 않는다. 유망한 모델을 추린 뒤에는 반드시 자체 평가 파이프라인을 돌려야 한다 — 그 설계를 다음 §10에서 다룬다.

10. 평가 파이프라인 설계하기

AI 애플리케이션의 성공은 종종 좋은 결과와 나쁜 결과를 구분하는 능력에 달려 있다. 이를 위해 신뢰할 수 있는 평가 파이프라인이 필요하다. 이 절은 개방형 과제 평가에 초점을 맞춘다 — 폐쇄형 과제 평가는 더 쉬우며, 개방형을 이해하면 폐쇄형은 쉽게 유추할 수 있다.

1단계 — 시스템의 모든 구성 요소 평가하기

실제 AI 애플리케이션은 여러 구성 요소·여러 단계로 이뤄진다. 엔드투엔드 출력과 각 구성 요소의 중간 출력을 독립적으로 평가해야 한다 — 이력서 PDF에서 현재 직장을 추출하는 애플리케이션이 ① PDF에서 텍스트 추출 ② 추출한 텍스트에서 현재 직장 찾기 두 단계로 이뤄진다면, 결과가 틀렸을 때 어느 단계 때문인지 각각 평가하지 않고서는 알 수 없다.

가능하면 턴 기반 평가와 작업 기반 평가를 함께 한다. 하나의 턴은 여러 단계·메시지로 구성될 수 있지만(예: 디버깅 중 모델이 먼저 하드웨어·파이썬 버전을 되묻는 경우) 여전히 하나의 턴으로 친다. 턴 기반 평가는 출력 하나하나의 품질을, 작업 기반 평가는 시스템이 작업을 완료했는지(몇 번의 대화로 해결했는지)를 잰다. 사용자가 가장 중요하게 여기는 것이 과제 완수이므로 작업 기반 평가가 더 중요하지만, 작업의 경계를 구분하기 어려운 경우가 많다(새 질의가 기존 작업의 후속인지 새 작업인지 판단이 어려운 경우). BIG-bench의 twenty_questions 벤치마크는 작업 기반 평가의 예다 — 한 모델 인스턴스(앨리스)가 개념을 고르면 다른 인스턴스(밥)가 예/아니오 질의만으로 알아맞히고, 성공 여부와 소요 질의 수로 점수를 매긴다.

2단계 — 평가 가이드라인 만들기

명확한 평가 가이드라인을 만드는 것이 평가 파이프라인에서 가장 중요한 단계다. 모호한 가이드라인은 모호한 점수로 이어진다. 애플리케이션이 해야 할 일뿐 아니라 하면 안 되는 일도 정의해야 한다 — 고객 지원 챗봇이 다가오는 선거 같은 제품과 무관한 질의에 답해야 하는지, 아니라면 범위 밖 입력을 어떻게 감지하고 대응할지까지 정해야 한다.

평가에서 가장 어려운 부분은 출력이 좋은지 판단하는 것이 아니라 "좋다"의 정의 자체다. 링크드인은 생성형 AI 애플리케이션 1년 운영을 돌아보며 평가 가이드라인을 만드는 것이 첫 장애물이었다고 밝혔다. 정확한 응답이 항상 좋은 응답은 아니다 — AI 기반 직무 평가 애플리케이션이 "당신은 이 자리에 전혀 맞지 않습니다"라고 답하면 정확할지 몰라도 지원자에게 도움이 되지 않으므로 좋은 응답이 아니다. 좋은 응답은 요구사항과 배경 사이 간극을 설명하고 그 간극을 좁힐 방법까지 알려줘야 한다. 랭체인의 2023년 AI 현황 조사에 따르면 사용자들은 평가에 평균 2.3개의 서로 다른 기준을 썼다 — 예를 들어 고객 지원 애플리케이션이라면 관련성(질의와 관련 있는가)·사실 일관성(컨텍스트와 사실적으로 일치하는가)·안전성(유해하지 않은가) 세 기준으로 정의할 수 있다.

기준마다 평가 시스템(이진법·1~5점·0~1 사이 등)을 정한 뒤, 예시와 함께 기준표를 만든다. 점수가 1인 응답은 어떤 모습이고 왜 그 점수를 받을 자격이 있는지 동료와 함께 검증해 보고, 사람들이 따르기 어려워하면 모호함을 없애도록 다듬는다. 이 가이드라인은 8장에서 다룰 학습 데이터 주석 작업에도 재사용된다.

평가 지표를 비즈니스 지표에 연결하기 — 고객 지원 챗봇의 사실 일관성이 80%라면 비즈니스에 어떤 의미인지 물어야 한다. 예컨대 사실 일관성 80%는 요청의 30%, 90%는 50%, 98%는 90%를 자동화할 수 있다는 식으로 매핑해 두면, 어떤 지표에 얼마나 투자할지 판단하는 데 도움이 된다. 이는 애플리케이션이 유용하려면 어떤 점수를 넘어야 하는지(유용성 임곗값)를 정하는 데도 쓰인다. 어떤 지표를 우선할지는 결국 고착도(DAU·WAU·MAU)·참여 지표 같은 비즈니스 목표와, 그것이 만들 수 있는 부작용(중독적 기능·자극적 콘텐츠) 사이의 균형이다.

3단계 — 평가 방법과 데이터 정의하기

기준과 기준표가 갖춰졌으면 평가에 쓸 방법과 데이터를 정의한다. 서로 다른 기준에는 서로 다른 방법이 맞는다 — 유해성은 작고 특화된 분류기, 관련성은 의미적 유사도, 사실 일관성은 AI 평가자를 쓰는 식이다. 같은 기준에도 방법을 섞을 수 있다 — 전체 데이터에는 저렴한 분류기로 낮은 품질의 신호를, 1%에는 비싼 AI 평가자로 고품질 신호를 주는 식으로 비용과 신뢰도를 함께 관리한다. 로그프롭을 쓸 수 있다면 적극 활용한다 — 세 클래스 예측 확률이 모두 30~40%라면 모델이 확신이 없다는 뜻이고, 한 클래스가 95%라면 확신하고 있다는 뜻이다. 자동 지표를 우선하되 운영 환경에서도 사람 평가를 두려워하지 말아야 한다 — 링크드인은 하루 최대 500개의 대화를 사람이 수동으로 평가하는 프로세스를 운영한다. 평가 방법은 실험 중뿐 아니라 운영 환경에서도 써야 한다는 점도 중요하다 — 운영 환경에는 참조 데이터가 없는 대신 실제 사용자가 있으므로, 사용자 피드백을 어떻게 모으고 활용할지 미리 생각해 둬야 한다(10장에서 다룬다).

평가 데이터 주석 달기 — 턴 기반·작업 기반 평가 모두 주석 달린 예시가 필요하다. 가능하면 실제 운영 데이터를 쓰고, 자연스러운 레이블이 없으면 사람이나 AI로 레이블을 단다(AI 생성 데이터는 8장에서 다룬다). 슬라이스 기반 평가로 데이터를 하위 집합으로 나눠 각각의 성능을 따로 보면 ① 소수 그룹에 대한 편향 축소 ② 특정 하위 집합에서만 성능이 나쁜 원인 디버깅 ③ 개선 영역 발굴 ④ 심슨의 역설 회피에 도움이 된다. 심슨의 역설은 한 모델이 모든 하위 그룹에서는 더 나은데 전체로 합치면 더 나빠 보이는 현상이다 — 그룹별 표본 크기가 다르면 전체 평균이 왜곡될 수 있기 때문이다. 좋은 평가를 위해서는 운영 데이터 분포를 대표하는 평가 세트, 자주 실수하는 예시로 구성된 세트, 애플리케이션이 처리하지 않아야 할 범위 외 평가 세트 등 여러 세트를 함께 갖추는 것이 좋다.

평가 세트 크기는 결과가 신뢰할 만큼 크면서도 실행 비용이 지나치지 않아야 한다. 예시 100개가 충분한지는 부트스트랩으로 확인할 수 있다 — 원래 100개에서 복원 추출로 100개 샘플을 여러 번 뽑아 각각 평가하고, 결과가 부트스트랩마다 크게 다르면(예: 한 번은 90%, 다른 번은 70%) 평가 세트가 신뢰할 만하지 않다는 뜻이다. 두 시스템(새 프롬프트 대 기존 프롬프트 등)을 비교할 때 95% 신뢰도로 차이를 확신하려면 얼마나 큰 표본이 필요한지에 대해, 오픈AI는 다음과 같은 대략적 추정치를 제시했다 — 점수 차이가 3배 줄어들 때마다 필요한 표본 수는 10배 늘어난다.

참고로 lm-evaluation-harness 벤치마크의 예시 수는 중앙값 1,000개, 평균 2,159개이며, Inverse Scaling 대회 주최측은 특히 예시를 합성할 때 최소 1,000개를 권장했다.

평가 파이프라인 평가하기 — 파이프라인 자체도 다음을 물어야 한다. ① 올바른 신호를 주는가(더 나은 응답이 실제로 더 높은 점수를 받는가) ② 얼마나 신뢰할 수 있는가(같은 파이프라인을 두 번 돌리면 다른 결과가 나오는가 — AI 평가자를 쓴다면 온도 파라미터를 0으로 고정해 재현성을 높여야 한다) ③ 지표 간 상관관계는 어떤가(§9에서 다룬 것처럼 상관관계가 높으면 둘 다 쓸 필요가 없고, 전혀 없다면 흥미로운 통찰이거나 신뢰할 수 없다는 신호다) ④ 비용·지연 시간을 얼마나 추가하는가(지연 시간을 줄이려 평가를 생략하는 것은 위험한 도박이다).

요구사항과 사용자 행동이 바뀌면 평가 기준·기준표·예시도 함께 진화해야 하지만, 평가 프로세스가 계속 바뀌면 결과를 개발 지침으로 쓸 수 없으므로 일정 수준의 일관성을 유지해야 한다. 반복하면서 평가 데이터·기준표·AI 평가자 프롬프트·샘플링 구성 등 변경될 수 있는 모든 변수를 실험 추적으로 기록해 두는 것이 좋다.

핵심 개념 정리

실무 체크리스트

• [ ] 이 애플리케이션의 평가 기준을 도메인 특화·생성 능력·지시 수행·비용/지연 시간 네 갈래로 각각 정의했는가
• [ ] 사실 일관성을 국소적/전역적 중 어느 기준으로 잴지 명확히 했는가
• [ ] 지시 수행 능력을 형식(자동 검증 가능)과 내용·문체(사람 또는 AI 평가자 필요)로 나눠 평가 방법을 다르게 설계했는가
• [ ] 하드 속성(라이선스·데이터·크기)과 소프트 속성(정확도·안전성)을 구분해 모델 선택 후보를 걸렀는가
• [ ] 자체 호스팅 대 API 사용을 일곱 기준(프라이버시·계보·성능·기능·비용·제어·온디바이스)으로 각각 점검했는가
• [ ] 참고하는 공개 리더보드가 우리 활용 사례에 맞는 벤치마크를 포함하는지 확인했는가
• [ ] 벤치마크 간 상관관계를 확인해 중복되는 벤치마크를 빼고 있는가
• [ ] 평가 대상 모델이 벤치마크 데이터로 오염됐을 가능성(n-gram 중복·퍼플렉시티)을 점검했는가
• [ ] 평가 파이프라인을 엔드투엔드뿐 아니라 각 구성 요소 단위로도 쪼개 평가하는가
• [ ] 평가 가이드라인에 "해야 할 일"뿐 아니라 "하면 안 되는 일"까지 정의했는가
• [ ] 평가 세트 크기가 충분한지 부트스트랩 등으로 확인했는가

연습문제

1. 유형: 기준 설계. 사내 문서를 요약해 주는 챗봇을 만든다고 하자. 이 애플리케이션의 도메인 특화 능력·생성 능력·지시 수행 능력·비용과 지연 시간 기준을 각각 한 문장으로 정의하라.
2. 유형: 판단. 팀이 데이터 프라이버시 정책상 외부로 데이터를 보낼 수 없지만, 가장 성능 좋은 모델은 상용 API로만 제공된다. 어떤 절충안을 검토할 수 있는지 §8의 일곱 기준을 참고해 두 가지 이상 제시하라.
3. 유형: 오류 찾기. 어떤 팀이 "우리 리더보드에서 1위인 모델이 우리 코드 생성 작업에서도 최고일 것이다"라고 결론 내렸다. 이 결론이 놓치고 있는 §9의 두 가지 위험(벤치마크 구성·데이터 오염)을 지적하라.
4. 유형: 설계. 고객 지원 챗봇의 사실 일관성이 85%로 측정됐다. 이 숫자를 "요청의 몇 %를 자동화할 수 있는가"라는 비즈니스 지표로 연결하려면 어떤 절차를 밟아야 하는지 §10 2단계를 참고해 서술하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-12, Tavily+Brave) — 책이 다룬 개념(평가 기준·파이프라인 설계)은 그대로 유효하다. 다만 이 장이 예시로 든 두 개의 대표 리더보드는 이후 크게 달라졌다.

• 이 장이 여러 차례 인용한 허깅페이스 오픈 LLM 리더보드는 공식적으로 은퇴했다 — 허깅페이스 팀은 해당 Space 토론에서 "2년간 커뮤니티에 재현 가능한 평가를 제공했지만 이제 운영을 마친다"고 공지했다. 지금은 이 리더보드 하나 대신 커뮤니티가 만든 여러 특화 리더보드(Hugging Face 리더보드 모음)로 분산됐다.
• 이 장이 언급한 LMSYS 챗봇 아레나는 이름이 두 번 바뀌었다 — 2024년 LMSYS 공식 블로그가 전용 사이트 lmarena.ai로 이전한다고 발표했고, 이후 2026년 1월 다시 "Arena"(arena.ai)로 리브랜딩됐다. 개념(익명 쌍대 비교 투표로 모델 순위를 매기는 방식)은 책이 설명한 그대로 유지된다.
• 책이 예시로 든 GPT-3.5·GPT-4·오픈 LLM 리더보드 초기 벤치마크(ARC-C·HellaSwag 등)는 지금은 더 어려운 세대(GPQA·MMLU-Pro·BBH 등, 이 장 §9가 이미 설명한 2024년 개편)로 대체된 것이 표준이다. 저자가 예상한 "포화 → 재편" 흐름이 계속되고 있다는 뜻이며, 이 장의 핵심 교훈(공개 벤치마크는 참고용이고 자체 평가 파이프라인이 필요하다)은 오히려 더 유효해졌다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식·논문, 생존 확인 2026-09-12)

• 평가 하네스 공식 저장소 — EleutherAI lm-evaluation-harness · OpenAI evals
• HELM(스탠퍼드) — crfm.stanford.edu/helm
• 허깅페이스 리더보드 계열 — Open LLM Leaderboard(은퇴 공지 및 후속 안내)
• Arena(옛 LMSYS 챗봇 아레나) — lmsys.org 공식 이전 공지
• 핵심 논문 — TruthfulQA · SelfCheckGPT · SAFE(Long-Form Factuality) · IFEval · INFOBench · RealToxicityPrompts

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 예시: 도메인 특화 능력 — "사내 문서(정책·용어)의 맥락을 올바르게 이해하고 요약에 반영하는가." 생성 능력 — "요약이 원문과 사실적으로 일치하고(사실 일관성) 문장이 자연스러운가(유창성)." 지시 수행 능력 — "요청된 길이·형식(불릿·문단 수 등)을 지키는가." 비용과 지연 시간 — "실시간 조회에 쓰기에 충분히 빠르고, 문서량 대비 토큰 비용이 감당 가능한가." 네 기준을 이 애플리케이션의 실제 요구에 맞춰 구체화하는 것이 핵심이며, 정답은 하나가 아니라 "각 기준이 도메인·형식·비용 중 무엇을 재는지 구분했는가"가 채점 포인트다.
2. (문제 2 정답) ① 온디바이스·프라이빗 배포 — 일부 상용 API 제공업체는 고객의 프라이빗 네트워크 안에 서비스를 배포할 수 있게 해 준다(§8 NOTE 참고). 이는 데이터가 밖으로 나가지 않으면서도 상용 모델의 성능을 쓸 수 있는 절충안이다. ② 오픈 소스 모델을 자체 호스팅 — 최고 성능은 아니더라도 격차가 좁혀지고 있는 오픈 소스 모델(§8 "성능")을 조직 내부 인프라에서 직접 운영해 프라이버시 요구를 지키는 방법이다. 두 선택지 모두 "가장 좋은 모델"을 포기하는 대신 "프라이버시라는 하드 속성"을 지키는 트레이드오프임을 언급하면 충분하다.
3. (문제 3 정답) 첫째, 벤치마크 구성의 문제 — 리더보드 1위는 그 리더보드가 고른 벤치마크 조합(예: MMLU·ARC-C 같은 일반 추론 벤치마크)에서 잘한다는 뜻일 뿐, 코드 생성 벤치마크를 포함하지 않는 리더보드라면 코드 생성 능력에 대해서는 아무것도 보장하지 않는다(§9 "이 리더보드에 어떤 벤치마크를 포함할 것인가"). 둘째, 데이터 오염의 문제 — 그 모델이 벤치마크 데이터를 학습 중에 이미 봤을 가능성이 있고, 그렇다면 리더보드 점수는 실제 능력이 아니라 암기를 반영한 것일 수 있다(§9 "데이터 오염"). 결론적으로 "리더보드 1위 = 우리 작업에 최적"이라는 추론은 벤치마크 구성과 오염 가능성 둘 다 확인하기 전에는 성립하지 않는다.
4. (문제 4 정답) ① 실제 운영 데이터에서 사실 일관성이 낮게 나온 요청들을 슬라이스로 뽑아, 그 요청들이 왜 자동화하기 어려운지(예: 결제·환불처럼 사실 오류의 대가가 큰 영역인지) 사람이 검토한다(§10 2단계 "슬라이스 기반 평가"). ② 자동화 가능/불가능 여부를 사람이 직접 라벨링한 소규모 표본을 만들어, 사실 일관성 점수 구간별로 "실제로 자동화해도 안전했는가"의 비율을 계산한다. ③ 이 표본에서 나온 대응 관계(예: "사실 일관성 85% 구간에서는 요청의 X%가 안전하게 자동화됐다")를 §10에서 설명한 매핑표(80%→30%, 90%→50%, 98%→90% 같은 형태) 형식으로 정리해 비즈니스 쪽과 공유한다. 핵심은 사실 일관성 점수 자체가 아니라 "그 점수가 비즈니스적으로 무엇을 뜻하는지"를 실측으로 연결하는 절차라는 점이다.